Increasingly the control of sophisticated electronic systems is handled by microprocessors. For example, control of network cards for HP's standard printer products contain an interface controlled by an embedded microprocessor. Testing of microprocessor controlled electronic systems is typically done during the product development phase using an in-circuit emulator which simulates the microprocessor of the product under development. However, unlike the microprocessor used in the developed product, the emulator provides the user with the tools required to (1) investigate and dynamically alter the component of the system's executable code, (2) set breakpoints, (3) perform single stepping, and (4) report on and change internal register contents of the microprocessor.
FIG. 1 shows a conventional emulator 110 used for testing an embedded microprocessor 116 on a PC board 114. Referring to FIG. 1, the ASIC on the PC board includes an embedded microprocessor and control circuitry specific to the ASIC. The pinout of the ASIC 112 typically includes a pin out for all the signals of the embedded microprocessor. A PC board 114 includes a socket 118 which corresponds to the pinout of the embedded microprocessor 116. The socket 118 corresponding to the embedded microprocessor is electrically connected to the signals pinned out from the ASIC. The embedded microprocessor for the developed product is disabled and a cable having a suitable probe is inserted into the socket 118 of the removed microprocessor. The disabled embedded microprocessor (external mode) allows the emulator to take control of the ASIC and simulate the embedded microprocessor signals.
It is common for emulators to provide a means to select whether the emulator processor executes the system's code from memory actually located in the product under development or instead from memory located within the emulator itself. The emulator microprocessor 120 is embedded in suitable control circuitry 124 and includes debug software which allows the emulator microprocessor to be started, stopped, and which allows the internal registers of the emulator microprocessor to be inspected or changed. This allows the developer to trace, trap, single step, and modify code on the fly.
The emulator is a powerful tool for diagnosing problems in the system hardware or firmware. However, there are problems associated with test and diagnosis using an emulator. For example, as ASICs are designed using faster technologies, their embedded processors will be clocked at higher and higher frequencies. The microprocessor 116 inside the ASIC will then be running at a higher clock rate than the external emulator 110 can match. If the microprocessor clock speed is lowered for debugging or problem diagnosis with an emulator, a risk is introduced, since the system being debugged is then different from the system shipped to the customer. The difference in microprocessor clock frequency between the embedded microprocessor 116 and the emulator processor 120 may mask firmware or hardware problems that are only apparent at the full clock speed of the embedded processor.
A further problem with using an emulator is that its use often requires the development of an additional prototype. In addition to the product prototype, a firmware prototype must be created that can accommodate the emulator tool. For instance, if the product uses a microprocessor embedded into the ASIC, a second prototype will need to be created that provides a microprocessor socket for the emulator connection. A lower frequency microprocessor clock may also be needed. This additional prototype adds engineering and material costs to the project budget that can be avoided.
Another problem with in-circuit emulators is their limited flexibility. For example, conventional in-circuit emulator tools are specific to the type of processor used in the design. Therefore, if the system designer of the electronic system under development decides to use a different microprocessor, a new emulator tool will have to be purchased. Further conventional emulators typically have standard pins that need to be accessible. Because emulators have a standard configuration with a standard pin out, it is difficult to reduce the number of pins on the ASIC.
With respect to ASICs, conventional emulators require the ASIC to bring out appropriate external pins so that the emulator tool can attach to the ASIC. This implies two modes of operation for the ASIC: internal microprocessor use and external microprocessor use. The two modes of operation have discrepancies in timing that the ASIC team must design and simulate for. This adds time to the ASIC design cycle due to the time required to do verification for both modes of operation.
An alternative test tool to an emulator is a debugger. Using a debugger requires a communications port, card based debug code and a user interface that manages the system attached to the communications port of the ASIC. In general a code developer can perform many of the same functions as an in-circuit emulator but at a design speed with the actual card design. Similar to an emulator, a serial debugger has the disadvantage of being specific to a particular microprocessor. Newer processor families can have this debugging functionality built into their designs. They may have an embedded communications port with provided software to allow for debugging.
A test and diagnosis system for testing an embedded microprocessor which can work with different microprocessors or microprocessor families, that allows code to be tested at product speed instead of at the speed of the emulator and that eliminates the need for more than one prototype to fully test the product under development is needed.